Q:
What can be done to prevent asynchronous OpenGL animation
driven via a Carbon Timer from drawing over menus?
A:
There are two cases to discuss in handling menus and asynchronous
animation.
- Using Carbon Events
- Using WaitNextEvent
Carbon Events:
One needs to support two events and toggle animation when
these are received. kEventMenuBeginTracking and kEventMenuEndTracking
indicate when the menu is being drawn for normal menus, pop-up
menus and contextual menus (which may actually track outside
the window bounds). When the kEventMenuBeginTracking event
is received the application should stop any asynchronous
OpenGL animation. This is best achieved by setting a flag
for your timer callback to read and not animate. One can
still respond to update events as the application normally
would. When the kEventMenuEndTracking is received re-enable
the applications animations and proceed as normal
WaitNextEvent:
One wants to stop animating when receiving mouseDown type
events whose part code is inMenuBar. Also do not initiate
any contextual or pop-up menus which are under application
control without toggling the hardware accelerated animation
off. Once the MenuSelect, etc. function has returned, it
is safe to animate once again. This will take care of most
cases but will not handle system initiated pop-up type menus
such as on a navigation services dialog. These situations
can be handled on a case by case basis by toggling the animation
off prior to bring up the system dialog.
These techniques allow simple handling of the deconfliction
of Mac OS 9 menus with asynchronous hardware accelerated
OpenGL blitting.
Mac OS X, of course, handles this integration automatically
and does not need any of these techniques.
[Jul 10 2001]
| 
